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Abstract 

Software developers are expected to protect concurrent accesses to shared regions of 
memory with some mutual exclusion primitive that ensures atomicity properties to a 
sequence of program statements. This approach prevents data races but may fail to pro¬ 
vide all necessary correctness properties.The composition of correlated atomic operations 
without further synchronization may cause atomicity violations. Atomic violations may be 
avoided by grouping the correlated atomic regions in a single larger atomic scope. Con¬ 
current programs are particularly prone to atomicity violations when they use services 
provided by third party packages or modules, since the programmer may fail to identify 
which services are correlated. In this paper we propose to use contracts for concurrency, 
where the developer of a module writes a set of contract terms that specify which meth¬ 
ods are correlated and must be executed in the same atomic scope. These contracts are 
then used to verify the correctness of the main program with respect to the usage of the 
module(s). If a contract is well defined and complete, and the main program respects 
it, then the program is safe from atomicity violations with respect to that module. We 
also propose a static analysis based methodology to verify contracts for concurrency that 
we applied to some real-world software packages. The bug we found in Tomcat 6.0 was 
immediately acknowledged and corrected by its development team. 


1 Introduction 

The encapsulation of a set of functionalities as services of a software module offers strong 
advantages in software development, since it promotes the reuse of code and ease maintenance 
efforts. If a programmer is unacquainted with the implementation details of a particular set 
of services, she may fail to identify correlations that exist across those services, such as data 
and code dependencies, leading to an inappropriate usage. This is particularly relevant in a 
concurrent setting, where it is hard to account for all the possible interleavings between threads 
and the effects of these interleaved calls to the module’s internal state. 

One of the requirements for the correct behavior of a module is to respect its protocol, 
which defines the legal sequences of invocations to its methods. For instance, a module that 
offers an abstraction to deal with files typically will demand that the programmer start by 
calling the method openO, followed by an arbitrary number of readO or write() operations, 
and concluding with a call to close (). A program that does not follow this protocol is incorrect 
and should be fixed. A way to enforce a program to conform to such well defined behaviors is to 
use the design by contract methodology [21], and specifying contracts that regulate the module 
usage protocol. In this setting, the contract not only serves as useful documentation, but may 
also be automatically verified, ensuring the client’s program obeys the module’s protocol [8,15]. 

The development of concurrent programs brings new challenges on how to define the proto¬ 
col of a module. Not only it is important to respect the module’s protocol, but is also necessary 
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void schedule () { 

Task t=taskQueue.next(); 


> 


if (t.isReady ( )) 
t.run ( ); 


Figure 1: Program with an atomicity violation. 


to guarantee the atomic execution of sequences of calls that are susceptible of causing atom¬ 
icity violations. These atomicity violations are possible, even when the individual methods 
in the module are protected by some concurrency control mechanism. Figure 1 shows part 
of a program that schedules tasks. The schedule () method gets a task, verifies if it is ready 
to run, and execute it if so. This program contains a potential atomicity violation since the 
method may execute a task that is not marked as ready. This may happen when another 
thread concurrently schedules the same task, despite the fact the methods of Task are atomic. 
In this case the isReadyO and runO methods should be executed in the same atomic context 
to avoid atomicity violations. Atomicity violations are one of the most common source of bugs 
in concurrent programming [20] and are particularly susceptible to occur when composing calls 
to a module, as the developer may not be aware of the implementation and internal state of 
the module. 

In this paper we propose to extend module usage protocols with a specification of the 
sequences of calls that should be executed atomically. We will also present an efficient static 
analysis to verify these protocols. 

The contributions of this paper can be summarized as: 

1. A proposal of contracts for concurrency addressing the issue of atomicity violations; 

2. A static analysis methodology to extract the behavior of a program with respect to the 
sequence of calls it may execute; 

3. A static analysis to verify if a program conforms to a module’s contract, hence that the 
module’s correlated services are correctly invoked in the scope of an atomic region. 

The remaining of this paper is organized as follows. In Section 2 we provide a specification 
and the semantics for the contract. Section 3 contains the general methodology of the analysis. 
Section 4 presents the phase of the analysis that extracts the behavior of the client program 
while Section 5 shows how to verify a contract based on the extracted information. Section 9 
follows with the presentation and discussion of the results of our experimental validation. The 
related work is presented in Section 10, and we conclude with the final remarks in Section 11. 


2 Contract Specification 

The contract of a module must specify which sequences of calls of its non-private methods must 
be executed atomically, as to avoid atomicity violations in the module’s client program. In the 
spirit of the programming by contract methodology, we assume the definition of the contract, 
including the identification of the sequences of methods that should be executed atomically is 
a responsibility of the module’s developer. 


Definition 1 (Contract). The contract of a module with public methods mi, • • •, to„ is of the 
form. 
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k. Ck- 

where each clause i is described by Cj, a star-free regular expression over the alphabet {mi, • • •, m„}. 
Star-free regular expressions are regular expressions without the Kleene star, using only the 
alternative (|) and the (implicit) concatenation operators. 

Each sequence defined in must be executed atomically by the program using the module, 
otherwise there is a violation of the contract. The contract specifies a finite number of sequences 
of calls, since it is the union of star-free languages. Therefore, it is possible to have the same 
expressivity by explicitly enumerating all sequences of calls, i.e., without using the alternative 
operator. We chose to offer the alternative operator so the programmer can group similar 
scenarios under the same clause. Our verification analysis assumes the contract defines a finite 
number of call sequences. 

Example Consider the array implementation offered by Java standard library, java.util .ArrayList. 
For simplicity we will only consider the methods add(obj), contains (obj), indexQf (obj), get (idx), 
setCidx, obj), remove (idx) , and sizeO. 

The following contract defines some of the clauses for this class. 

1. containsindexQf 

2. indexQf (remove | set | get) 

3. size (remove | set| get) 

4. add indexQf. 

Clause 1 of ArrayList ’s contract denotes the execution of contains () followed by indexOf () 
should be atomic, otherwise the client program may confirm the existence of an object in the 
array, but fail to obtain its index due to a concurrent modification. Clause 2 represents a 
similar scenario where, in addition, the position of the object is modified. In clause 3 we deal 
with the common situation where the program verifies if a given index is valid before accessing 
the array. To make sure the size obtained by sizeC is valid when accessing the array we 
should execute these calls atomically. Clause 4 represents scenarios where an object is added 
to the array and then the program tries to obtain information about that object by querying 
the array. 

Another relevant clause is contains indexQf (set | remove), but the contract’s semantic al¬ 
ready enforces the atomicity of this clause as a consequence of the composition of clauses 1 and 2, 
as they overlap in the indexQf () method. 

3 Methodology 

The proposed analysis verifies statically if a client program complies with the contract of a 
given module, as defined in Section 2. This is achieved by verifying that the threads launched 
by the program always execute atomically the sequence of calls defined by the contract. 

This analysis has the following phases: 

1. Determine the entry methods of each thread launched by the program. 

2. Determine which of the program’s methods are atomically executed. We say that a 
method is atomically executed if it is atomic^ or if the method is always called by atom¬ 
ically executed methods. 

^ An atomic method is a method that explicitly applies a concurrency control mechanism to enforce atomicity. 
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3. Extract the behavior of each of the program’s threads with respect to the usage of the 
module under analysis. 

4. For each thread, verify that its usage of the module respects the contract as defined in 
Section 2. 

In Section 4 we introduce the algorithm that extracts the program’s behavior with respect 
to the module’s usage. Section 5 defines the methodology that verifies whether the extracted 
behavior complies to the contract. 

4 Extracting the Behavior of a Program 

The behavior of the program with respect to the module usage can be seen as the individual 
behavior of any thread the program may launch. The usage of a module by a thread t of a 
program can be described by a language L over the alphabet mi, • • •, nin, the public methods 
of the module. A word mi ■ • ■ m„ S L if some execution of t may run the sequence of calls 
mi, • • •, m„ to the module. 

To extract the usage of a module by a program, our analysis generates a context-free 
grammar that represents the language L of a thread t of the client program, which is represented 
by its control flow graph (CFG) [1]. The CFG of the thread t represents every possible path the 
control flow may take during its execution. In other words, the analysis generates a grammar 
Gt such that, if there is an execution path of t that runs the sequence of calls mi, • • •, m„, then 
mi • • • m„ G C{Gt). (The language represented by a grammar G is denoted by C{G).) 

A context-free grammar is especially suitable to capture the structure of the CFG since 
it easily captures the call relations between methods that cannot be captured by a weaker 
class of languages such as regular languages. The first example bellow will show how this 
is done. Another advantage of using context-free grammars (as opposed to another static 
analysis technique) is that we can use efficient algorithms for parsing to explore the language 
it represents. 


Definition 2 (Program’s Thread Behavior Grammar). The grammar Gt = {N,T,, P, S) is 
build from the CFG of the client’s program thread t. 

We define, 

• N, the set of non-terminals, as the set of nodes of the CFG. Additionally we add non¬ 
terminals that represent each method of the client’s program (represented in calligraphic 
font); 

• S, the set of terminals, as the set of identifiers of the public methods of the module under 
analysis (represented in bold); 

• P, the set of productions, as described bellow, by rules 1-5; 

• S, the grammar initial symbol, as the non-terminal that represents the entry method of 
the thread t. 

For each method f () that thread t may run we add to P the productions respecting the 
rules 1-5. Method f O is represented by P. A CFG node is denoted by a : If;], where a is the 
non-terminal that represents the node and v its type. We distinguish the following types of 
nodes: entry, the entry node of method P] mod.h(), a call to method h() of the module mod 
under analysis; g(), a call to another method gO of the client program; and return, the return 
point of method P. The succ : N V{N) function is used to obtain the successors of a given 
GFG node. 
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if a : |entry], 

{P —>■ a} U {a —>■ /3 1 /3 £ succ{a)} C P 

(1) 

if a : |mod.h()]. 

{a —J- h/3 1 /3 £ succ{a)} C P 

(2) 

if a : |g()]. 

{a —J- t?/3 1 /3 £ succ{a)} C P 



where G represents g() 

(3) 

if a : [return]. 

{a —> e} C P 

(4) 

if a : [otherwise]. 

{a —>■ /3 1 /3 £ succ{a)} C P 

(5) 

No more productions belong to 

P. 



Rules 1-5 capture the structure of the CFG in the form of a context-free grammar. In¬ 
tuitively this grammar represents the flow control of the thread t of the program, ignoring 
everything not related with the module’s usage. For example, if f g € C{Gt) then the thread t 
may invoke, method f O, followed by g(). 

Rule 1 adds a production that relates the non-terminal representing method f O, to the 
entry node of the CFG of f (). Calls to the module under analysis are recorded in the grammar 
by the Rule 2. Rule 3 handles calls to another method g() of the client program (method gO will 
have its non-terminal Q added by Rule 1). The return point of a method adds an e production 
to the grammar (Rule 4). All others types of CFG nodes are handled uniformly, preserving 
the GFG structure by making them reducible to the successor non-terminals (Rule 5). Notice 
that only the client program code is analyzed. 

The Gt grammar may be ambiguous, i.e., offer several different derivations to the same 
word. Each ambiguity in the parsing of a sequence of calls mi ■ ■ ■ £ ^{Gt) represents 

different contexts where these calls can be executed by thread t. Therefore we need to allow 
such ambiguities so that the verification of the contract can cover all the occurrences of the 
sequences of calls in the client program. 

The language C{Gt) contains every sequence of calls the program may execute, i.e., it 
produces no false negatives. However C{Gt) may contain sequences of calls the program does 
not execute (for instance calls performed inside a block of code that is never executed), which 
may lead to false positives. 

Examples Figure 2 (left) shows a program that consists of two methods that call each other 
mutually. Method f() is the entry point of the thread and the module under analysis is 
represented by object m. The control flow graphs of these methods are shown in Figure 2 (right). 
According to Definition 2, we construct the grammar Gi = (A^i, Ei, Pi, ^i), where 


Ni = {P, g, A, B, G, D, E, F, G, H, I, J, K, L, M}, 
El = {a,b,c,d}, 

and Pi has the following productions: 


T ^ A 

g^G 

A^B 

H ^cl 

B ^aC 

I ^ J\M 

C-^D\E 

J -^gK 

D-^gE 

K ^dL 

E^hF 

L -> PM 

F e 

M 
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fO gO 

G 



Figure 2: Program with recursive calls using the module m (left) and respective CFG (right). 

A second example, shown in Figure 3, exemplifies how the Definition 2 handles a flow 
control with loops. In this example we have a single function f (), which is assumed to be the 
entry point of the thread. We have G 2 = {N 2 , 'S 2 , P 2 , S 2 ), with 

N2 = {P,A,B,C,D,E,F,G, H}, 

S 2 = {a,b,c,d}, 

82 = P. 

The set of productions P 2 is, 

J ^ A 
A^B 

B^&G\aG 
G ^D\E 
D ^hE. 

5 Contract Verification 

The verification of a contract must ensure all sequences of calls specified by the contract are 
executed atomically by all threads the client program may launch. Since there is a hnite 
number of call sequences dehned by the contract we can verify each of these sequences to check 
if the contract is respected. 

The idea of the algorithm is to generate a grammar the captures the behavior of each thread 
with respect to the module usage. Any sequence of the calls contained in the contract can then 
be found by parsing the word (i.e. the sequence of calls) in that grammar. This will create a 
parsing tree for each place where the thread can execute that sequence of calls. The parsing 
tree can then be inspected to determine the atomicity of the sequence of calls discovered. 

Algorithm 1 presents the pseudo-code of the algorithm that verifies a contract against a 
client’s program. For each thread t of a program P, it is necessary to determine if (and where) 
any of the sequences of calls defined by the contract w = mi, • • •, m„ occur in P (line 4). To do 
so, each of the these sequences are parsed in the grammar (line 5) that includes all words 
and sub-words of Gt- Sub-words must be included since we want to take into account partial 


A —>• cP 
F ^ B 
G->dH 
H e 
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Figure 3: Program using the module m (left) and respective CFG (right). 


Algorithm 1 Contract verification algorithm. 

Require: P, client’s program; 

C, module contract (set of allowed sequences). 
1: for t £ threads (P) do 
2: Gt <— make_grammar(t) 

3; G^ £- subword_grammar(G't) 

4; for w £ C do 

5; T •<—parse(GC w) 

6; for r G T do 

7; N ^ lowest_common_ancestor(T, rc) 

8; if -irun_atomically(A) then 

9; return ERROR 

10: return OK 


traces of the execution of thread t, i.e., if we have a program m.aO; m.bO; m.cO; m.dO; we 
are able to verify the word b c by parsing it in G(. Notice that G( may be ambiguous. Each 
different parsing tree represents different locations where the sequence of calls mi, • • •, m„ may 
occur in thread t. Function parse () returns the set of these parsing trees. Each parsing tree 
contains information about the location of each methods call of mi, ■ • m^ in program P (since 
non-terminals represent CFG nodes). Additionally, by going upwards in the parsing tree, we 
can find the node that represents the method under which all calls to mi, • • •, m^ are performed. 
This node is the lowest common ancestor of terminals mi, • • •, m„ in the parsing tree (line 7). 
Therefore we have to check the lowest common ancestor is always executed atomically (line 
8) to make sure the whole sequence of calls is executed under the same atomic context. Since 
it is the lowest common ancestor we are sure to require the minimal synchronization from 
the program. A parsing tree contains information about the location in the program where a 
contract violation may occur, therefore we can offer detailed instructions to the programmer 
on where this violation occurs and how to fix it. 

Grammar Gt can use all the expressivity offered by context-free languages. For this reason 
it is not sufficient to use the LR{-) parsing algorithm [17], since it does not handle ambiguous 
grammars. To deal with the full class of context-free languages a GLR parser (Generalized 
LR parser) must be used. GLR parsers explore all the ambiguities that can generate different 
derivation trees for a word. A GLR parser was introduced by Tomita in [24]. Tomita presents 
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void atomic run() 

f (); 
m . c () ; 

> 

void f () { 

m . a () ; 

gO; 

> 

void g() { 

while (cond) 
m . b () ; 

} 


7^ —y J' c 

g^A 
A^B\e 
B ^hA 



Figure 4: Program (left), simplified grammar (center) and parsing tree of a b b c (right). 


a non-deterministic versions of the LR{0) parsing algorithm with some optimizations in the 
representation of the parsing stack that improve the temporal and spacial complexity of the 
parsing phase. 

Another important point is that the number of parsing trees may be infinite. This is due 
to loops in the grammar, i.e., derivations from a non-terminal to itself (A => • • • => A), which 
often occur in Gt (every loop in the control flow graph will yield a corresponding loop in the 
grammar). For this reason the parsing algorithm must detect and prune parsing branches that 
will lead to redundant loops, ensuring a finite number of parsing trees is returned. To achieve 
this the parsing algorithm must detect a loop in the list of reduction it has applied in the 
current parsing branch, and abort it if that loop did not contribute to parse a new terminal. 

Examples Figure 4 shows a program (left), that uses the module m. The method runO is the 
entry point of the thread t and is atomic. In the center of the figure we shown a simplified 
version of the Gt grammar. (The G( grammar is not shown for the sake of brevity.) The 
runO, f 0, and gO methods are represented in the grammar by the non-terminals TZ, T, and 
g respectively. If we apply Algorithm 1 to this program with the contract G = {a b b c} the 
resulting parsing tree, denoted by r (line 6 of Algorithm 1), is represented in Figure 4 (right). 
To verify all calls represented in this tree are executed atomically, the algorithm determines 
the lowest common ancestor of a b b c in the parsing tree (line 7), in this example TZ. Since 
TZ is always executed atomically (atomic keyword), it complies to the contract of the module. 

Figure 5 exemplifies a situation where the generated grammar is ambiguous. In this case 
the contract is G = {ab}. The figure shows the two distinct ways to parse the word ab 
(right). Both these trees will be obtained by our verification algorithm (line 5 of Algorithm 1). 
The first tree (top) has T as the lowest common ancestor of a b. Since T corresponds to the 
method f (), which is executed atomically, so this tree respects the contract. The second tree 
(bottom) has TZ as the lowest common ancestor of a b, corresponding to the execution of the 
else branch of method run(). This non-terminal (77.) does not correspond to an atomically 
executed method, therefore the contract is not met and a contract violation is detected. 

6 Analysis with Points-to 

In an object-oriented programming language the module is often represented as an object, 
in which case we should differentiate the instances of the class of the module. This section 
explains how the analysis is extended to handle multiple instances of the module by using 
points-to information. 

To extend the analysis to points-to a different grammar is generated for each allocation site 
of the module. Each allocation site represents an instance of the module, and the verification 
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Figure 5: Program (left), simplified grammar (center) and parsing tree of a b (right). 



void run() { 
if (...) 
f (); 

else { 

m . a () ; 

g () ; 

} 

} 

void atomic f() •[ 

m . a() ; 

g () ; 

} 

void atomic g() { 

m . b () ; 

} 


Algorithm 2 Contract verification algorithm with points-to information. 
Require: P, client’s program; 

C, module contract (set of allowed sequences). 

1: for t G threads(P) do 

2 : for a G mod_alloc_sites(t) do 

3; Gt^ G- make_grammar(t, a) 

4; G[ ■<— subword_grammar(Gt^) 

5; for w G C do 

6; T G- parse(G( , w) 

7: for T e T do “ 

8; iV ^ lowest_common_ancestor(r, w) 

9; if -'run_atomically(A) then 

10: return ERROR 

11: return OK 


algorithm verifies the contract words for each allocation site and thread (whereas the previous 
algorithm verified the contract words for each thread). The new algorithm is shown in Algo¬ 
rithm 2. It generated the grammar G*^ for a thread t and module instance a. This grammar 
can be seen as the behavior of thread t with respect to the module instance a, ignoring every 
other instance of the module. 

To generate the grammar Gt„ we adapt the Definition 2 to only take into account the 
instance a. The grammar generation is extended in the following way: 


Definition 3 (Program’s Thread Behavior Grammar with points-to). The grammar Gj = 
{N, E, P, S) is build from the CFG of the client’s program thread t and an object allocation 
site a, which represents an instance of the module. 

We define N, E, P and S in the same way as Definition 2. 

The rules remain the same, except for rule 2, which becomes: 
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void replace(int o, int n) 

{ 

if (array.contains(o)) 

{ 

int idx=array.indexOf(o); 
array.set(idx,n); 

} 

> 

Figure 6: Examples of atomic violation with data dependencies. 


a : |mod.h()] and mod can only point to a 

(6) 

{a ^ h/3 1 /3 G succ{a)} C P 


a : |mod.h()| and mod can point to a 

(7) 

{a ^ h/3 1 /3 G succ{a)} C P 


{a ^ /3 1 /3 G succ(a)} C P 


a : |mod.h()| and mod cannot point to a 

(8) 

{a ^ /3 1 /I G succ{a)} C P 



Here we use the points-to information to generate the grammar, and we should consider 
the places where a variable can point-to. If it may point-to onr instance a or another instance 
we consider both possibilities in the Rule 7 of Definition 3. 

7 Contracts with Parameters 

Frequently contract clanses can be refined by considering the flow of data across calls to the 
module. For instance Listing 6 shows a procedure that replaces an item in an array by another. 
This listing contains two atomicity violations: the element might not exist when indexOf () is 
called; and the index obtained might be outdated when setO is executed. Naturally, we can 
define a clause that forces the atomicity of this sequence of calls as contains indexOf set, 
but this can be substantially refined by explicitly require that a correlation exists between 
the indexOf 0 and setO calls. To do so we extend the contract specification to capture the 
arguments and return values of the calls, which allows the user to establish the relation of 
valnes across calls. 

The contract can therefore be extended to accommodate this relations, in this case the 
clause might be 

contains(X) Y=indexOf(X) set(Y,_). 

This clause contains variables (X,Y) that mnst satisfy unification for the clause to be ap¬ 
plicable. The underscore symbol (_) represents a variable that will not be used (and therefore 
reqnires no binding). Algorithm 1 can easily be modified to filter out the parsing trees that 
correspond to calls that do not satisfy the unification required by the clause in question. 

In our implementation we require a exact match between the terms of the program to satisfy 
the unification, since it was sufficient for most scenarios. It can however be advantageous to 
generalize the unification relation. For example, the calls 

array.contains(o); 
idx=array.indexOf(o+l); 
array.set(idx,n); 

also imply a data dependency between the first two calls. We should say that A unifies 
with B if, and only if, the valne of A depends on the value of B, which can occur due to value 
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manipulation (data dependency) or control-flow dependency (control dependency). This can 
be obtained by an information flow analysis, such as presented in [5], which can statically infer 
the variables that influenced the value that a variable hold on a specific part of the program. 

This extension of the analysis can be a great advantage for some types of modules. As 
an example we rewrite the contract for the Java standard library class, java.util.ArrayList, 
presented in Section 2: 

1. contains(X) indexOf(X) 

2. X=indexOf(_) (remove(X) | set(X,_) |get(X)) 

3. X=size() (remove(X) | set(X,_) |get(X)) 

4. add(X) indexQf(X). 

This contract captures in detail the relations between calls that may be problematic, and 
excludes from the contract sequences of calls that does not constitute atomicity violations. 

8 Prototype 

A prototype was implemented to evaluate our methodology. This tool analyses Java programs 
using Soot [25], a Java static analysis framework. This framework directly analyses Java 
bytecode, allowing us to analyse a compiled program, without requiring access to its source 
code. In our implementation a method can be marked atomic with a Java annotation. The 
contract is also defined as an annotation of the class representing the module under analysis. 
The prototype is available in https://github.com/trxsys/gluon. 

8.1 Optimizations 

To achieve a reasonable time performance we implemented a few optimizations. Some of 
these optimizations reduced the analysis run time by a few orders of magnitude in some cases, 
without sacrificing precision. 

A simple optimization was applied to the grammar to reduce its size. When constructing the 
grammar, most control flow graph nodes will have a single successor. Rule 5 (Definition 2) will 
always be applied to these kind of nodes, since they represent an instruction that does not call 
any function. This creates redundant ambiguities in the grammar due to the multiple control 
flow paths that never use the module under analysis. To avoid exploration of redundant parsing 
branches we rewrite the grammar to transform productions of the form A f3Bd, B ^ a to 
A —^ PaS, if no other rule with head B exists. For example, an if else that do not use the 
module will create the productions A^B,A—)-C,B^D,C^D. This transformation will 
reduce it to A D, leaving no ambiguity for the parser to explore here. This optimization 
reduced the analysis time by at least one order of magnitude considering the majority of the 
tests we performed. For instance, the Elevator test could not be analyzed in a reasonable time 
prior to this optimization. 

Another optimization was applied during the parsing phase. Since the GLR parser builds 
the derivation tree bottom-up we can be sure to find the lowest common ancestor of the ter¬ 
minals as early as possible. The lowest common ancestors will be the first non-terminal in the 
tree covering all the terminals of the parse tree. This is easily determined if we propagate, 
bottom-up, the number of terminals each node of the tree covers. Whenever a lowest common 
ancestor is determined we do not need further parsing and can immediately verify if the cor¬ 
responding calls are in the same atomic context. This avoids completing the rest of the tree 
which can contain ambiguities, therefore a possibly large number of new branches is avoided. 

Another key aspect of the parsing algorithm implementation is the loop detection. To 
achieve a good performance we should prune parsing branches that generated unproductive 
loop as soon as possible. Our implementation guarantees the same non-terminal never appears 
twice in a parsing tree without contributing to the recognition of a new terminal. 
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Table 1: Optimization Improvements. 


Optimization 

Improvement 

Grammar Simplihcation 

428% 

Stop Parsing at LCA 

? 

Subword Parser 

3% 


To achieve a better performance we also do not explicitly compute the subword gram¬ 
mar (G(). We have modihed our GLR parser to parse subwords as described in [23]. This 
greatly improves the parser performance because constructing G] introduces many irrelevant 
ambiguities the parser had to explore. 

The Table 1 show how much the of the optimizations improve the analysis performance. 
These results are build from an test made to stress the performance of gluon but is consistent 
with real applications. The Improvement column show how much of an improvement that 
particular optimization contributes to the analysis. The Stop Parsing at LCA cause an im¬ 
provement that we were not able to measure since the test was unable to complete in reasonable 
time. 

8.2 Class Scope Mode 

Gluon normally analyzes the entire program, taking into account any sequence of calls that can 
spread across the whole program (as long as they are consecutive calls to a module). However 
this is infeasible for very large programs so, for these programs, we ran the analysis with for 
each class, ignoring calls to other classes. This will detect contract violations where the control 
flow does not escape the class, which is reasonable since code locality indicates a stronger 
correlations between calls. 

This mode of operation can be useful to analyze large programs as they might have very 
complex control flow graphs and thus are infeasible to analyze with the scope of the whole 
program. 

In this mode the grammar is build for each class instead of each thread. The methods of 
the class will create non-terminals T\^- • -iJ-n) just as before. The only change in creating this 
grammar is that we create the productions S' —>■ | • • • | as the starting production of 
the grammar (S being the initial symbol). This means that we consider the execution of all 
methods of the class being analyzed. 

9 Validation and Evaluation 

To validate the proposed analysis we analyzed a few real-world programs (Tomcat, Lucene, 
Derby, OpenJMS and Cassandra) as well as small programs known to contain atomicity vi¬ 
olations. These small programs were adapted from the literature [2-4, 16,19,22, 27] and are 
typically used to evaluate atomicity violation detection techniques. We modified these small 
programs to employ a modular design and we wrote contracts to enforce the correct atomic 
scope of calls to that module. Some additional clauses were added that may represent atom¬ 
icity violations in the context of the module usage, even if the program do not violate those 
clauses. 

For the large benchmarks analyzed we aimed to discover new, unknown, atomicity viola¬ 
tions. To do so we had to create contracts in an automated manner, since the code base was too 
large. To automate the generation of contracts we employ a very simplistic approach that tries 
to infer the contract’s clauses based on what is already synchronized in the code. This idea is 
that most sequences of calls that should be atomic was correctly used somewhere. Having this 
in mind we look for sequences of calls done to a module that are used atomically at least two 
points of the program. If a sequence of calls is done atomically in two places of the code that 
might indicate that these calls are correlated and should be atomic. We used these sequences 
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Table 2: Validation results. 


Benchmark 

Clauses 

Contract 

Violations 

False 

Positives 

Potential 

AV 

Real 

AV 

SLOC 

Time (s) 

ICFinder 

Static 

ICFinder 

Final 

Allocate Vector [16] 

1 


0 

0 


183 

0.120 

- 

- 

CoordOS |2| 

4 


0 

0 


151 

0.093 

- 

- 

Coordn4 [3] 

2 


0 

0 


35 

0.039 

- 

- 

Jigsaw [27] 

1 


0 

0 


100 

0.044 

121 

2 

Local [2] 

2 


0 

0 


24 

0.033 

- 

- 

Knight [19] 

1 


0 

0 


135 

0.219 

- 

- 

NASA [2] 

1 


0 

0 


89 

0.035 

- 

- 

Store |22| 

1 


0 

0 


621 

0.090 

- 

- 

StringBuffer [3] 

1 


0 

0 


27 

0.032 

- 

- 

UnderReportiiig [27] 

1 


0 

0 


20 

0.029 

- 

- 

VectorFail [22] 

2 


0 

0 


70 

0.048 

- 

- 

Account [27] 

4 

2 

0 

0 

2 

42 

0.041 

- 

- 

Arithmetic DB [19] 

2 

2 

0 

0 

2 

243 

0.272 

- 

- 

Connection [4] 

2 

2 

0 

0 

2 

74 

0.058 

- 

- 

Elevator [27] 

2 

2 

0 

0 

2 

268 

0.333 

- 

- 

OpenJMS 0.7 

6 

54 

10 

28 

4 

163K 

148 

126 

15 

Tomcat 6.0 

9 

157 

16 

47 

3 

239K 

3070 

365 

12 

Cassandra 2.0 

1 

60 

24 

15 

2 

192K 

246 

- 

- 

Derby 10.10 

1 

19 

5 

7 


793K 

522 

122 

16 

Lucene 4.6 

3 

136 

21 

76 

0 

478K 

151 

391 

2 


as our contracts, after manually filtering a few irrelevant contracts. This is a very simple way 
to generate contracts, which should ideally be written by the module’s developer to capture 
common cases of atomicity violations, so we can expect the contracts to be more ftne-tuned to 
better target atomicity violations if the contracts are part of the regular project development. 

Since these programs load classes dynamically it is impossible to obtain complete points-to 
information, so we are pessimistic and assumed every module instance could be referenced 
by any variable that are type-compatible. We also used the class scope mode described in 
Section 8.2 because it would be impractical to analyze such large programs with the scope of 
the whole program. This restrictions did not apply to the small programs analyzed. 

Table 2 summarizes the results that validate the correctness of our approach. The table 
contains both the macro benchmarks (above) and the micro benchmarks (bellow). The columns 
represent the number of clauses of the contract (Clauses); the number of violations of those 
clauses (Contract Violations); the number of false positives, i.e. sequences of calls that in fact 
the program will never execute (False Positives); the number of potential atomicity violations, 
i.e. atomicity violations that could happen if the object was concurrently accessed by multiple 
threads (Potential AV); the number of real atomicity violations that can in fact occur and 
compromise the correct execution of the program (Real AV); the number lines of code of the 
benchmark (SLOC); and the time it took for the analysis to complete (the analysis run time 
excludes the Soot initialization time, which were always less than 179s per run). 

Our tool was able to detect all violation of the contract by the client program in the 
microbenchmarks, so no false negatives occurred, which supports the soundness of the analysis. 
Since some tests include additional contract clauses with call sequences not present in the test 
programs we also show that, in general, the analysis does not detect spurious violations, i.e., 
false positives.^ A corrected version of each test was also verifted and the prototype correctly 
detected that all contract’s call sequences in the client program were now atomically executed. 
Correcting a program is trivial since the prototype pinpoints the methods that must be made 
atomic, and ensures the synchronization required has the finest possible scope, since it is the 
method that corresponds to the lowest common ancestor of the terminals in the parse tree. 

The large benchmarks show that gluon can be applied to large scale programs with good 
results. Even with a simple automated contract generation we were able to detect 10 atomicity 
violations in real-world programs. Six of these bugs where reported (Tomcat Derby 

^In these tests no false positives were detected. However it is possible to create situations where false 
positives occur. For instance, the analysis assumes a loop may iterate an arbitrary number of times, which 
makes it consider execution traces that may not be possible. 

^https://issues.apache.org/bugzilla/show_bug.cgi?id=56784 
^https://issues.apache.org/jira/browse/DERBY-6679 
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Cassandra ®), with two bugs already fixed in Tomcat 8.0.11. The false positives incorrectly 
reported by gluon were all due to conservative points-to information, since the program loads 
and calls classes and methods dynamically (leading to an incomplete points-to graph). 

ICFinder [18] uses a static analysis to detect two types of common incorrect composition 
patterns. This is then filtered with a dynamic analysis. Of the atomicity violations detected 
by gluon none of them was captured by ICFinder, since they failed to match the definition of 
the patterns. 

It is hard to directly compare both approaches since they use very different approaches. 
Loosely speaking, in Table 2 the ICFinder Static column corresponds to the Contract Viola¬ 
tions, since they both represent the static methodology of the approaches. The ICFinder Final 
column cannot be directly compared with the Real AV column because “ICFinder Final” may 
contain scenarios that not represent atomicity violations (in particular if ICFinder does not cor¬ 
rectly identify the atomic sets). ICFinder Final cannot also be compared with “Potencial AV” 
since “Potencial AV” is manually obtained from “Contract Violations”, and “ICFinder Final” is 
the dynamic filtration of “ICFinder Static”. In the end the number of bugs reported by gluon 
was 6, with 2 bugs confirmed and with fixes already applied, 1 bug considered highly unlikely, 
and 3 bugs pending confirmation; ICFinder has 3 confirmed and fixed bugs on Tomcat. ® 

The performance results show our tool can run efficiently. For larger programs we have to 
use class scope mode, sacrificing precision for performance, but we still can capture interesting 
contract violations. The performance of the analysis depends greatly on the number of branches 
the parser explores. This high number of parsing branches is due to the complexity of the 
control flow of the program, offering a huge amount of distinct control flow paths. In general 
the parsing phase will dominate the time complexity of the analysis, so the analysis run time 
will be proportional to the number of explored parsing branches. Memory usage is not a 
problem for the analysis, since the asymptotic space complexity is determined by the size of 
the parsing table and the largest parsing tree. Memory usage is not affected by the number 
of parsing trees because our GLR parser explores the parsing branches in-depth instead of 
in-breadth. In-depth exploration is possible because we never have infinite height parsing trees 
due to our detection of unproductive loops. 

9.1 ICFinder 

ICFinder tries to infer automatically what a module is, and incorrect compositions of pairs of 
calls to modules. 

Two patterns are used to detect potencial atomicity violations in method calls compositions: 

• USE: Detects stale value errors. This pattern detects data or control flow dependencies 
between two calls to the module. 

• COMP: If a call to method a() dominates b() and b() post-dominates a() in some place, 
that is captured by this pattern. This means that, for each piece of code involving two 
calls to the module (a() and bO), if a() is always executed before b() and b() is always 
executed after a(), it is a COMP violation. 

Both this patterns are extremely broad and contain many false positives. To deal with this 
the authors filter this results with a dynamic analysis that only consider violations as defined 
in [26]. This analysis assumes that the notion of atomic set was correctly inferred by ICFinder. 


10 Related Work 

The methodology of design by contract was introduced by Meyer [21] as a technique to write 
robust code, based on contracts between programs and objects. In this context, a contract 

®https://issues.apache.org/jira/browse/CASSANDRA-7757 
®https://issues.apache.org/bugzilla/show_bug.cgi?id=53498 
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specifies the necessary conditions the program must met in order to call the object’s methods, 
whose semantics is ensured if those pre-conditions are met. 

Cheon et al. proposes the use of contracts to specify protocols for accessing objects [8]. 
These contracts use regular expressions to describe the sequences of calls that can be executed 
for a given Java object. The authors present a dynamic analysis for the verification of the 
contracts. This contrasts to our analysis which statically validates the contracts. Beckman et 
al. introduce a methodology based on typestate that statically verifies if a protocol of an object 
is respected [4]. This approach requires the programmer to explicitly unpack objects before 
it can be used. Hurlin [15] extends the work of Cheon to support protocols in concurrent 
scenarios. The protocol specification is extended with operators that allow methods to be 
executed concurrently, and pre-conditions that have to be satisfied before the execution of a 
method. This analysis is statically verified by a theorem prover. Theorem proving, in general, 
is very limited since automated theorem proving tend to be inefficient. 

Peng Liu et al. developed a way to detect atomicity violations caused by method com¬ 
position [18], much like the ones we describe in this paper. They define two patterns that 
are likely to cause atomicity violations, one capturing stale value errors and the other one by 
trying to infer a correlation between method calls by analyzing the control flow graph (if a() is 
executed before b() and b() is executed after aO). This patterns are captured statically and 
then filtered with a dynamic analysis. 

Many works can be found about atomicity violations. Artho et al. in [2[ define the notion of 
high-level data races, that characterize sequences of atomic operations that should be executed 
atomically to avoid atomicity violations. The definition of high-level data races do not totally 
capture the violations that may occur in a program. Praun and Gross [27[ extend Artho’s 
approach to detect potential anomalies in the execution of methods of an object and increase 
the precision of the analysis by distinguish between read and write accesses to variables shared 
between multiple threads. An additional refinement to the notion of high-level data races was 
introduced by Pessanha in [10[, relaxing the properties defined by Artho, which results in a 
higher precision of the analysis. Farchi et al. [11[ propose a methodology to detect atomicity 
violations in the usage of modules based on the definition of high-level data races. Another 
common type of atomicity violations that arise when sequencing several atomic operations 
are stale value errors. This type of anomaly is characterized by the usage of values obtained 
atomically across several atomic operations. These values can be outdated and compromise 
the correct execution of the program. Various analysis were developed to detect these types 
of anomalies [3,6,10]. Several other analysis to verify atomicity violations can be found in 
the literature, based on access patterns to shared variables [19,26], type systems [7], semantic 
invariants [9], and other specific methodologies [12-14]. 

11 Concluding Remarks 

In this paper we present the problem of atomicity violations when using a module, even when 
their methods are individually synchronized by some concurrency control mechanism. We 
propose a solution based on the design by contract methodology. Our contracts define which 
call sequences to a module should be executed in an atomic manner. 

We introduce a static analysis to verify these contracts. The proposed analysis extracts the 
behavior of the client’s program with respect to the module usage, and verifies whether the 
contract is respected. 

A prototype was implemented and the experimental results shows the analysis is highly 
precise and can run efficiently on real-world programs. 
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12 Appendix 

12.1 Grammar Example 


©Contract ( clauses = 
class Module 
{ 

public Module () •[ }■ 

public void a() •[ } 

public void b() •[ }■ 

public void c() •[ }■ 

} 

public class Main 

{ 

private static Module m; 

private static void f() 

{ 

m . c () ; 

} 

©Atomic 

private static void g() 

{ 

m . a () ; 
m . b () ; 

f () ; 

} 

public static void main(String [] args) 

{ 

m = new Module (); 

for (int i=0; i < 10; i++) 

if (iy.2 == 0) 
m . a () ; 

else 

m . b () ; 

f () ; 
gO; 

} 

} 


Figure 7: Program. 
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Start: A 
A -> B 
D -> E F 
E -> X 
F -> G 
G -> H 
B -> C 
C -> D 
L -> M 
L -> N 
M -> 0 
N -> R 
0 -> a P 
H -> I 
I -> K 
I -> J 
J -> L 
K -> T U 
BF -> BG 
U -> V W 
BG -> b BH 
T -> BA 
BH -> T BI 
W -> epsilon 
BI -> epsilon 

V -> BD 

BB -> c BC 

q -> S 

BC -> epsilon 

P -> q 
BD -> BE 
S -> H 
BE -> a BF 
R -> b q 

Y -> Z 
X -> Y 

Z -> epsilon 
BA -> BB 


Figure 8: Non-optimized grammar. 
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Start; A’ 
A’ -> A 
A -> I 
L -> b I 
L -> a I 
I -> L 
I -> T V 
T -> c 
V -> a b T 


Figure 9: Optimized grammar. 
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